知識ゼロから学ぶソフトウェアテスト 【改訂版】
https://scrapbox.io/files/5f4a4530dc050c00216c517b.png
基本情報
書籍名: 知識ゼロから学ぶソフトウェアテスト 【改訂版】
ページ数: 229
金額: 紙 2400+税 / Kindle 2160+税
ステータス
本の概要
本の感想
論文などの背景を根拠にしつつ、専門用語や前提知識をできるだけ必要としない説明を行っているため読みやすい。
個別の技法については別の本でふかぼりする必要がある。
2013年の本のため、テスト業界の進化がそれほど早くないとはいえ、現在の事情には合わない箇所もありそう(Windowsのリリースペースについての記述など、影響はないけど2020年現在の状況には合っていない)
お勧めの読者
テストの概要を掴みたいひと
扱っている分野
動機、価格
入手金額: 2376円
入手フォーマット: Kindle
入手動機: 読みやすくて良い本だと紹介されたため
動機は満たされたか: はい
読書メモ
ハイライト(黄) | 位置No. 520
ステートメントカバレッジでは、分岐条件のすべてはカバーできない場合があります。そこで、より強力なカバレッジ手法であるブランチカバレッジについて説明します。
ハイライト(黄) | 位置No. 592
カバレッジテストですべてのバグを見つけるのは理論的に不可能です。
ハイライト(黄) | 位置No.657-661
図24のように100%に近づくほど、カバレッジテストにかかるテスト費用は等比級数的に増加していきます。なぜなら、境界値分析(3章で詳述)をちゃんと行っても目標のカバレッジには届かず、テスト担当者がコードを見てカバレッジを上げなければならない状態に陥るからです。
https://scrapbox.io/files/60ebce1d789f7d0022ca21c6.png
ハイライト(黄) | 位置No. 1121
平たくいえばアドホックテスト、ランダムテストとは、行き当たりばったり、何ら考えもなしに入力や操作を行う手法です* 12。あらかじめ同値分割や境界値分析などを考える必要性がないので、一見効率的であるようにも思えますが、あまり役には立ちませんBEI90。テスト手法にのっとったやり方で見つかるバグであっても、ランダムテストでは見つからないようなバグは多岐に渡ります。 とはいえ、このテスト手法は荒っぽいやり方ながら結構な数のバグが見つかってしまうところが問題です。 ハイライト(黄) | 位置No. 1316
最悪のケースでは、要求仕様で満たされている内容を羅列するようなテストケース
ハイライト(黄) | 位置No. 1330
早過ぎるテストケース作成は著しいソフトウェアテストの工数増大をもたらします。
ハイライト(黄) | 位置No. 1339
初期に書かれたそれほど練られていないテストケースを繰り返すことにはあまり意味がありません。逆に必要なことは、 テストを実行しながら、どこかほかの部分に問題がないかを考え、そこをテストすることである ソフトウェアで弱いところを見つけたら、そこに重点を置き、その部分を十分にテストする
ハイライト(黄) | 位置No. 1379
弱いエリアを見つける
ハイライト(黄) | 位置No. 1428
探索的テストをしない理由はありません。 しかし探索的テスト(もしくはほかの手法)単独の手法で品質を確保することはできないので、探索的テスト(もしくはほかのテスト手法)だけでテストを終了することはできないのも事実です。
ハイライト(黄) | 位置No. 1560
要求定義通りのテストケースを書かない
ハイライト(黄) | 位置No. 1566
パフォーマンステストで発見されるバグは最悪のバグ
ハイライト(黄) | 位置No. 1591
パフォーマンステストに関しても、負荷テストと同様、テストの自動化* 8 は必須です。
ハイライト(黄) | 位置No. 1630
機密性(Confidentiality) アクセスを認可された者だけが、特定の情報にアクセスできることを確実にすること 完全性(Integrity) 「情報及びその処理方法が正確で、かつ完全であること」を維持・保護すること 可用性(Availability) 認可された利用者が必要なときに、特定の情報及び関連する資産にアクセスすることを確実にする
ハイライト(黄) | 位置No. 1724
ファジングテスト
ハイライト(黄) | 位置No. 1792
バグの数の曲線を測るという作業はあまり意味がありませんが*
ハイライト(黄) | 位置No. 1840
こういった曲線の図をテストケース実行の成功/失敗に対して描いても、大して意味がありません。最終的にプロジェクトではテストケースに対するバグの発生をゼロにするからです(もちろん 修正しないと判断したバグも含みます)。なのでゼロになったあとは、ずっとテストしないのでゼロのまま、MTBFは無限大で、理論的にはこのソフトウェアは永遠にバグが出ないということになります。まあそんなことはあり得ないので、テストケースの実行に対してバグ曲線を描くのはほとんど意味がないのです。
ハイライト(黄) | 位置No. 2185
James Bachの典型的なソフトウェアテストのリスク要因を挙げますBAA00。 複雑度 何か複雑なものを使っているか。たとえば非常に複雑な暗号モジュールがある場合 新規性 何か新しい技術を使っているか。たとえば今までにまったくなかったタイプのCPUを使っている場合 変更 何か大きな危険性のある変更を行っているか 上位依存性 開発製品がある製品に依存しているか。たとえば開発するアプリケーションが未だ出荷されていないWindowsの新しいバージョンに依存している場合など(Windowsは実際いつ出るか判らないことが ハイライト(黄) | 位置No. 2284
テストツールを使用するとテストマネージャの仕事量は激減します。
ハイライト(黄) | 位置No. 2308
テストケースを実行するうえで、どの順番で実行するかについては考えておいた方がよいでしょう。ただ単にリストの上から順に実行するのではなく、リスクを考えながら順番を判断すべきです